home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 001083_timbl@www3.cern.ch _Tue May 11 16:48:28 1993.msg < prev    next >
Internet Message Format  |  1994-01-24  |  4KB
  1. Return-Path: <timbl@www3.cern.ch>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA13073; Tue, 11 May 93 16:48:28 MET DST
  4. Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
  5.     id AA22283; Tue, 11 May 1993 17:09:21 +0200
  6. Received: by www3.cern.ch (NX5.67c/NX3.0S)
  7.     id AA03736; Tue, 11 May 93 17:04:07 +0100
  8. Date: Tue, 11 May 93 17:04:07 +0100
  9. From: Tim Berners-Lee <timbl@www3.cern.ch>
  10. Message-Id: <9305111604.AA03736@www3.cern.ch>
  11. Received: by NeXT.Mailer (1.87.1)
  12. Received: by NeXT Mailer (1.87.1)
  13. To: John C Klensin <KLENSIN@infoods.mit.edu>
  14. Subject: Re: Mail addresses as URLs
  15. Cc: www-talk@nxoc01.cern.ch, uri@bunyip.com
  16. Reply-To: timbl@nxoc01.cern.ch
  17.  
  18.  
  19. > Date: Tue, 11 May 1993 10:13:49 -0400 (EDT)
  20. > From: John C Klensin <KLENSIN@infoods.mit.edu>
  21. > 
  22.  
  23. > Tim,
  24. > 
  25.  
  26. > I think the idea of permitting an email address is reasonable,  
  27. although
  28. > it brings us another step closer to a uniform human locator, as in  
  29. "if
  30. > 'mailto' then why not 'faxto', 'telephoneto', 'postto' and so on.
  31.  
  32. Yes.  I guess we have to be a little more definite about the object
  33. which is being located.  I prefer to see the web as something with
  34. a state which one can alter, rather than a recipe book scripts behind  
  35. the buttons.  The
  36. "mailto:" URL suggests the well defined concept of a mailbox which
  37. may or may not contain documents and may or may not have
  38. restricted access. Perhaps "mailbox:" would be better than "mailto:".
  39. Moving a document into somone's mail box is just like moving a
  40. file into a directory: it is an operation with pre- and  
  41. postconditions.  It just happens that mail uses a particular
  42. protocol which is optimised for particular operations,
  43. has a wide penetration, etc., but can otherwise be treated
  44. with the same user interface metaphor as news and retrieval.
  45.  
  46. "telephoneto" like "telnet" doesn't fit into that model, and
  47. so is less usefully integrated.
  48.  
  49. > However you are going to need to be extremely careful about syntax.   
  50. The 
  51.  
  52. > correct model should be able to accomodate _any_ valid RFC822  
  53. address,
  54. > implying not only "mailto:usermailbox@domain" but including the 
  55.  
  56. >   Personal Name <usermailbox@domain>
  57. > form and several others.  
  58.  
  59.  
  60. Is there not a subsyntax for the usermailbox@domain bit, with the
  61. comment personal Name removed?  It would have the example of being
  62. a little closer to something which one can test for equality.
  63.  
  64. > RFC1327 forms of X.400 addresses projected into the RFC822  
  65. environment
  66. > also mean that we need to be very careful about quoting and  
  67. structure,
  68. > since those addresses are heavily solidus (/)-laden.
  69.  
  70. Yes. I had intended to keep "=" in the URL spec
  71. so that it could be used to map /attribute=value/ such as x400.
  72. If you directly quote an RFC822 address, then you run across
  73. the fact MIME uses = instead of %, and all kinds of things.
  74. Would it be possible to remove all RFC822 quoting and apply
  75. URL escaping as a reversable and well-defined transformation
  76. which would presvent the horrible results of layered escaping?
  77.  
  78.  
  79. > This makes me quite hesitant about forms like Thomas Bruce's
  80. >        mailto://some.mail.host.dom/somebody
  81. > because it implies that we will need to very carefully work out and
  82. > document transformation rules for all of the different variations  
  83. of
  84. > RFC822 addresses into and out of this format.  It would be easier,  
  85. and
  86. > safer, to use RFC822 addresses in as literal a form as possible, so  
  87. we
  88. > could just refer to that document and its descendants.
  89.  
  90.  
  91. I agree completely.  Tom's format was designed to look as like
  92. as possible to http URLs, but there is in the
  93. news:artic@leid a precedent for exactly the same reasons for
  94. keeping the original as uncorrupted as possible.
  95.  
  96. >    --john
  97. > 
  98.  
  99.  
  100.  Tim